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ABSTRACT 



In a distributed system where many processors are connected by a network and 
communicate using message passing, many users can be allowed to access the same facilities. 
A public utility is usually an expensive or limited resource whose use has to be regulated, 
A guardian is an abstraction that can be used to regulate the use of resources by 
scheduling their access, providing protection, and implementing recovery from hardware 
failures. We present a language construct called a primitive serializer which can be used 
to express efficient implementations of guardians in a modular fashion. We have developed 
a proof methodology for proving strong properties of network utilities eg. the utility is 
guaranteed to respond to each request which it is sent This proof methodology is 
illustrated by proving properties of a guardian which manages two hardcopy printing 
devices. 



V Guardians 

I - INTRODUCTION 

1.1 — Semantics 

Programs written for distributed systems with many processors can be plagued by 
subtle errors arising in unpredictable situations. To limit these problems, it is necessary 
that the primitives for dealing with concurrency provided by our programming languages 
have simple intuitive interpretations and completely unambiguous definitions. They should 
also be powerful enough to express simple solutions to simple or common problems and to 
admit rigorous proof methods. For both of these reasons we have been looking for 
primitives whose semantics are mathematically well defined. We want each primitive 
construct to denote a mathematical object which defines the behavior of the primitive 
Our methods of proof are ultimately based on theorems about these mathematical objects. 

In a similar vein mathematical semantics must be provided for any well defined 

specification language. Ideally a specification language should be powerful enough so that 

it is convenient to express both the partial specifications of the abstractions of the user 

f-\ (such as airline reservation systems and disk head schedulers) as well as the abstractions of 

the programming language (such as monitors and serializes). 

This paper makes use of a description system in which the properties of actors 
can be described. A distinctive feature of our description system is that it specifies the 
required behavior of objects rather than their physical representation. Instead of using 
predicates to state the interface requirements between modules, descriptions are attached to 
the data manipulated by each module. The idea is to allow properties of actors to be 
specified in the form of descriptions that appear directly in the code 
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Guardians are abstractions that can regulate the use of a resource by scheduling 
its access, providing protection, and implementing recovery from hardware failures which 
manifest themselves as time-outs. In this paper we develop partial specifications and proofs 
for an hardcopy server for two printing devices. In a subsequent paper we will present 
partial specifications and proofs for other guardians such as a readers- writers guardians 
using different scheduling algorithms, a guardian for a disk spindle that optimizes head 
motion, etc. 
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1. 3 — Primitive Serializes 

The guardians in this paper are' implemented using primitive serializes which are a 
further development of serializers JHewitt and Atkinson: 1977, 1979]. Primitive serializes 
are more flexible than previous serializers in that they have less built-in machinery. Their 
more primitive character gives them the ability to efficiently implement the facilities (such 
as queues) that were provided by previous serializers as well as to implement new facilities 
that were not provided before. 

Unlike previous serializers, primitive serializers do not have any implicit 
nondeterminism in the evaluation of synchronization conditions. Additional flexibility 
comes form the fact that primitive serializers can explicitly deal with actors which act as 
customers to whom replies should be sent. Our notion of a customer is a generalization of 
the notion of a continuation to deal with the issues of concurrency, protection, and 
interrupts. Customers can be dealt with as any other actors. For instance they can be 
put into queues for implementing scheduling policies. 

At the same time primitive serializers maintain the advantages of serializers over 
other published proposals for synchronization primitives such as monitors [Hoare- 1 974; 
Brinch-Hansen: 1973] and Communicating Sequential Processes [Hoare: 1978} The examples 
considered in this paper are used to illustrate the advantages of using the actor model for 
partially specifying and proving properties of guardians 
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II - A DESCRIPTION SYSTEM 

III — Goals 

The main goal of our description system is to conveniently use the following kinds 
of descriptions: ] 

PARTIAL descriptions are used to express whatever properties of an object 
happen to be known at particular point in time if they are incomplete. Partial descriptions 
are important in partial specifications because it is impossible to arrive at complete 
specifications for a large software system all at once. They are important in proofs because 
in a proof some properties are given whereas others must be derived. 

INCREMENTAL descriptions which enable us to further describe objects when 

more information becomes available and are a necessary feature for the use of partial 

descriptions. Incremental descriptions are important in proofs and incremental 

specifications because all of the properties are not available at one time but must be 

>*■*% derived and evolved with time. 

MULTIPLE descriptions which enable us to ascribe multiple overlapping 
descriptions to an object which is used for multiple purposes. Multiple descriptions are 
important in multiple specifications and proofs because different properties of an object 
might be useful in different contexts. 

We would like to point out the usefulness of description systems to describe partial 
specifications for programs. In fact the assumptions and the constraints on the objects 
manipulated by a program are an integral part of the program and can be used both as 
checks when the programming is running and as useful information which can be exploited 
by other systems which examine the program such as translators, optimizers, indexers, etc. 
We believe that bugs occurring in programs are frequently caused by the violation of 
implicit assumptions about the environment in which the program is intended to operate. 
Therefore many advantages can be drawn by a system that encourages the programmer to 
state such assumptions explicitly, and by a system which is able to detect when they are 
violated. 

The fundamental axiom of our description system can be stated as follows: 



4 Guardians 

/^description^ is <descriptiOn 2 » and «description 2 > is <description 3 » 
then ^description^ IS <description 3 >) 

and is called the Axiom of Transitivity of Predication. It .implies that inheritance holds 
in our description system and that all descriptions are organized in a large tangled 
hierarchy in some ways similar to the ones in Roger's Thesaurus and the Micropaedia of 
the Encyclopedia Britannica. 

Our description system is designed to allow us to provide multiple partial 
descriptions of objects. For example (a Cartesian.complex [imaginary_part: 0]) is a description of 
an instance of a Cartesian complex number whose imaginary_part is 0. Note that we have 
used the indefinite article "a" to mark descriptions of instances of a concept Descriptions 
can in turn be multiply described. For example the following command describes 
(a Cartesian.complex) as being ' (a Number) and as having two attributes, namely a reaLpart and 
an im3ginary_part each of which must be a Real. 

The description below says that a Cartesian.complex is a Number: 
((a Cartesian.complex) /S (a Number)) 

A Cartesian.complex can be further described as follows: 

((a Cartesian.complex) is (a Cartesian.complex [real_part: (a Real)] [imaginary jsart: (a Real)])) 

Note that by using the concept Cartesian.complex twice in the above description that we have 
specified that every Cartesian.complex has two attributes real_part and imaginary .part which each 
have as value a Real. 

Note that the is statement is asymmetric so that it would be incorrect to say 
(a Cartesian.complex) /S (a Real) 

since a Cartesian complex number is not always a real number. Furthermore it would also 
be incorrect to say 

(a Cartesian.complex) /S-t(a Real) 
since some Cartesian complex numbers are Real. 
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Our description -system successfully deals with an important distinction that has 
plagued most previous systems which rely on inheritance. Given that 3+4i is a 
Cartesian_comp!ex and that Cartesian_complex is an Aigebraicjieid, one IS not allowed to conclude 
that 3+4i is an Aigebraicjieid. Note that this mistake will not occur in our system because 
the rule of transitivity of predication does not apply to the following two descriptions: 

3+4i is (a Cartesian_complex) 

Cartesian_complex is (an Aigebraicjieid) 

While Cartesian_complex is described as being an Algebraic field, an instance of Cariesian_complex 
such as (a Cartesian^complex) cannot be considered as an Algebraic field, Logicians as long ago 
as Aristotle have known that Cartesian_complex must not be confused with (a Cartesian.complex). 
However, a good notation was lacking in which to axiomatize the difference. 

The user can describe a Real x as being a Cartesian_complex with reaLpart x , and 
imaginary part 0: 

({a Real) which Js =x) is (a Cartesian_complex [reaLpari: =x] [iroaginary_part: 0]) 

The character = is used to mark local identifiers. Local identifiers play a role in the 
description system similar to the role played by free identifiers in formulas in the 
quantificational calculus: they can be bound to any object. For example since 

(3 i$ (a Real)) 

it follows that 

(3 is (a Cartesian_comptex [reaLpart: 3] [imaginary.part: 0.])) 

The user can partially describe a Carterian.complex with reaLpart x and iroaginary_part 
as being x which is a Real: 

((a Cartesian_complex [reaLpart: =x] [imaginary_part: 0]) whichjs =x) is (a Real) 

Notice that we have just established a mutual dependency among our descriptions because 
we have described Real in terms of Cartesian_complex and vice versa. This will enable us to 
view either one as the other in the appropriate circumstances. 



6 Guardians 

The above descriptions express some of the relations between Real and 
Cartesian complex numbers. We believe that it is important that a description system allows 
information to be presented in an incremental fashion. For example it should be possible 
for the user to later further describe Cartesian.comptex numbers relative to other kind of 
numbers. 

(a Cartesian.compiex [real_part: *x] [imaginary .part: =y]) i$ 
(a Number) and 

(a Polar.complex [magnitude: =r (a Real)]} 
SUCh_that 

(r is (x 2 + y 2 ) (l / 2) ) 

It is important to realize that in giving the above descriptions the user is not 
making anv commitments as to the physical representation of complex numbers. The 
possibility is still open that complex numbers will be physically represented in Cartesian, 
Polar form, some mixture, or still some other alternative physical representation. It is even 
possible that both physical representations will cohabit the same system This last 
possibility is especially "important in distributed systems where the autonomy of nodes on 
the network must be respected. 

II. 2 - Descriptions of Communications 

Messages are sent to guardians in communications. A request is a communication 
which always contains a message and a customer: 

(a Request) .1$ 

(n 

(a Communication) 

{a Request [message: (a Message)] [customer: (a Customs)])) 

The concept of a customer generalizes ihe notion of a continuation in the lambda calculus 
programming languages [A. Church, C Strachey, L. Morris, C. Wadsworth, J. Reynolds, C 
Hewitt, Sussman and Steele, etc.]. When an actor receives a message M and customer | it 
has the right to negotiate with c for the funds necessary to process the message M. This 
negotiation process implements the notion of bankers proposed in [Hewitt, Bishop, and 
Steigen 1973]. Eventually the customer c should be sent a Response which is either a Reply 
or Complaint for the message: M. 
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Another kind of communication is a Response which is either a reply or a 
complaint: 

(a Response) is 

(a Communication) and 

<Cl' ■ . . . . ;.■■" 

(a Reply [message: {a Message)]) 
(a Complaint [message: (a Message)])) 



III -- PRIMITIVE SERIALIZERS 

The design goals for monitors is that they were intended to be a structuring 
construct for implementing operating systems. There have been some attempts to develop 
useful proof rules for monitors [Howard: 1076; G jessing: 1977; Hoare: 1974; Owicki; 1978] 
Serializers [Atkinson and Hewitt: 1977, 1979] are a further step toward these goals. 
However the language construct developed by Hewitt and Atkinson may be too complicated 
to be useful both as a formal foundation and as a basis for the proof methodology. In the 
study we present here the approach has been reversed. Instead of designing a desirable set 
of primitives and then trying to describe their semantics in a formal way, we started with a 
basic primitive with a simple semantics. 

The syntax of a simple primitive serializer in Actl fe 

(create_$erialized_actor B) 

A primitive serializer can be used to create an actor S whose behavior can change 
as a result of the communication which it receives. At any given time S is either locked 
or unlocked. It has a current behavior (which is another actor). When S is created it is 
unlocked. When the first communication arrives, the serializer becomes locked and the 
communication received is sent to B. 

Executing a command of the form 

{tran$mit_to t c) 

will result in the transmission of the communication actor c to the target actor t. 
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In addition to possibly transmitting some communications, B computes a new 
behavior NB using a command of the form 

{become NB) 

The actor NB is installed as the next behavior of S. The actor S then becomes unlocked 
and thus able to accept the next message. An important consideration in the design of 
efficient serializers is that they should remain locked for as brief a time as possible. 

A behavior will typically be implemented using create_unserialized_actor expression 
which has the following syntax: 

{create_un$erialized_actor 

( pattern Jor_communication j received body ^) 

(^iSO! Jow^-CJyniyl'^j received bod/:)) 

If an actor created by a create_un$erialized_actor expression receives a communication C 
which matches any of the patternjor.communicationj , then the corresponding body^ is executed 
to produce the next behavior. If C matches more than one of the patternJor_communication ; , 
then an arbitrary one of the corresponding bodyj is selected to be executed. 

Note that there are three separate events which must occur before a 
communication C can be accepted by a serialized actor T. First it must be transmitted in 
a transmission event of the form 

{a Transmission [target: T] [communication: CJ) 

Next it must arrive in an arrival event of the form 

[an Arrival [target: TJ [communication: CJ) 

Hardware modules called arbiters arc used to establish an arrival ordering for all 
communications sent to T. Finally it must be accepted in an acceptance event of the 
form 

(an Acceptance [recipient: T] [communication: CJ) 
Communications are accepted in the order in which they arrive. The acceptance marks a 
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transition in which the target changes from unlocked to locked. Thus if a serialized actor 
becomes locked then no more messages can be accepted until it unlocks. 



IV - A SIMPLE EXAMPLE 



IV. 1 — Descriptions of Messages for Checking Account 

As a simple example of how primitive serializes can be used, we give the 
implementation of a very simple checking account guardian. 

There are two kinds of messages which must be dealt with by the guardian: 
Withdrawal and Deposit which can be described as follows: 

(a Withdrawal) is 

(a Message) and 

(a Withdrawal [amount: (a Non_ne&ativeJJ$_currency)J) 

(a Deposit) i$ 

(a Message) and 

(a Deposit [amount: (a Non_negativeJJS_currency)]) 

which says that both kinds of messages have an attribute named amount which must be a 
non-negative US currency. 

(a Transaction^completed^report) IS (a Reply) 

(a Transaction_not_completed [reason: overdraft]) is (a Complaint) 



IV. 2 — A Concurrent Case Expression 

Clearly some kind of conditional test is needed in implementations. Use will be 
made of select_case_for expressions of the following form: 

{select_case_for expression 

( pattern j produces body ±) 

( pattern n produces body n ) 
[none_of Jhejabove: alternative_body] ) 
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which when evaluated first evaluates expression to produce a value V If the value V matches 
any of the pattern) then the corresponding bodyj is executed and its value is the value of the 
select_ca$e_for expression. If the value V matches more than one of the patterrij then an 
arbitrary one of the corresponding bodyy is selected to be executed. This rule has the 
advantage that it makes bodyj more modular since it depends only on pattern; , making it 
easy to add more selections later. Thus the rule of concurrent consideration of cases 
encourages the construction of programs which are more modifiable. The programs are 
also more robust since the addition of new cases is less likely to introduce bugs in already 
existing cases. 

We shall say that two activities are concurrent if it is possible for them to occur at 
the same. The concurrent case statement facilitates efficient implementation by allowing 
concurrent matching of expression against the patterns. This ability is important in 
applications where a large amount of time is required to determine whether or not 
conditions hold. Thus the rule of concurrent consideration of cases enables some programs 
to be implemented more efficiently. 

If the value V does not match any of the pattern; then alternative.body is executed. 
This rule provides the ability to have the patterns represent special cases leaving the 
alternative_body to deal with the general case if none of the special cases apply. 

IV. 3 — A Simple Guardian 

In this section we present an implementation of a checking account guardian- which 
guards a checking account to ensure that timing errors do when concurrent attempts are 
made to deposit or withdraw money. An implementation of the checking account guardian 
is given below: 

{describe (ct eate_account [initial_batance: =i (a Non_negative_US_currency)]) 
[is: (a Serialized_ador [respondsjo: (1*1 (a Deposit) (a Withdrawal))])] 

;renpom<>sto deposit and withdrawal mrssagts arc guaranteed 
[implementation: 
{create_serialized_actor 

(an Account [balance: i]))]) 

The behavior of an Account is defined below: 



/*"" ll *\ 



11 Guardians 



{describe (an Account [balance: (a Non__negativeJJS_currency)]) 
[implementation: 

(create_un$erialized_actor 

((a Request [message: (a Withdrawal [amount: =a])] [customer: =c]) received 
($elect_ca$e_for balance 
((> a) produces 

{transmit^to c (3Transaction_compietedj*eport)) 
(become (an Account [balance: (balance - a)]))) 
((< a) produces 

(transmit_to c (3 Transaction_noLcompleted [reason: overdraft]))))) 
((a Request [message: (a Deposit [amount: =d])J [customer: =c]) received 
{transmit_to t (aTransaction_completedj'eport)) 
{become (an Account [balance: (balance + d)]))))]) 



V - IMPLEMENTING A HARDCOPY SERVER 

Implementing a hardcopy server on a distributed system provides a concrete 
example to illustrate the advantages of primitive serializers. The following definition shows 
a program to create a guardian for two hardcopy devices. The example illustrates how a 
primitive serializer can be used to implement a guardian that protects more than one 
resource. Finally, the program below illustrates the use of nondeterminism in primitive 
serializers since if both devices are idle, then a nondeterministic choice is made which 
should serve the next Hardcopyj-equest since it doesn't matter which one is chosen. 



V. 1 — A Concurrent Conditional Expression 

! • •'•■'. - ■ ' ' ■ - 

The implementation of the hardcopy server given below makes use of a conditional 
construct of the following form: 

(select_one_of 

W condition ^ then body ^ ) 

(/7condition n then body n ) 

[none_of Jhe_above: alt ernativ e^body]) 

If any conditio nj holds then the corresponding body ; is executed. If more than one of 
the condition j hold then an arbitrary one of the corresponding body; is selected to be 
executed. The user will be warned if more than one of the conditionj can hold 
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simultaneously and the execution of the corresponding bodyj do not have equivalent effects. 
The rule of concurrent consideration of conditions encourages programs which are more 
robust, modular, easily modifiable, and efficient than is possible with the conditional 
expression in LISP for the reasons which are enumerated in the discussion of the 
select_caseJor expression. If none of the condition) hold then alternative_body is executed. 

The reader will probably have noticed that the select_one_of construct is very 
similar to the select_case_for construct which we introduced earlier in this paper. The 
reason for introducing both constructs is that whereas the $etect_ca$e_for construct is 
often quite succinct and readable there are cases such as the implementation below in 
which it is desirable to concurrently test properties of more than one actor in a single 
conditional expression making the use of $elect_one_of preferable. 

The $elect_one_of expression is different from the conditionals of McCarthy, 
Dijkstra, etc. in several important respects. The conditions of select_one_of have been 
generalized to allow pattern matching as in the pattern directed programming languages 
PLANNER, QA-4, POPLER, CONNIVER, etc. Notice that our concurrent conditional 
expression is different from the usual nondeterministic conditional in that if any of the 
conditions hold then the body of one of them must be selected for execution even if the 
evaluation of some other condition does not terminate (cf. [Manna and McCarthy: 1970, 
Paterson and Hewitt: 1971, Friedman and Wise: 1978P. 



V.2 -- Implementation of a Hardcopy Server 
Below we give the implementation of the hard copy server. 
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(describe (create_hardcopy_server =devicej =device?) 

[is: (a SeriaIized_actor 

[responds Jo: (a PrinLrequestJ] 
[accepts: 
■<Cl 

(a Completion [device: (ill device^ devu^)]) 

(a Breakdownj-eport [device: (l!i devicej device 2 )]))])] 

[implementation: 

(label thejlardcopy ..server ;the_hardcopy .server is the name of the actor created by Serialize 
(create_serialized_actor 

(a Hard_copy .server [queue: (an Empty_queue)] [devicej>tateji: idle] [device_stat© 2 : idle])) 

where ;the following is lexically nested in the above 

(describe (a Hard_copy_server [queue: (a Queue [each_element: (a Printj-equest)])] 

[device_statej: (ft idle printing broken)] 

[device_state 2 : (ft idle printing broken)]) 
[preconditions: (implies 

(queue is -»(a Queue [sequence: []])) 

(and (device^tatej is -.idle) (device_state 2 i$ ->idie)))] 

[implementation: 

(create_unserialized_actor 
((a Print.request) =thej-equest received 

(ponder (a Hardcopy_server [queue: (a Queue [alljbut _rear: queue] [rear: the.request])]))) 
;invoke the ponder transition with the_request at the rear of the queue 

((a Completion [device: device = j] [response: =r] [customer: -c]) received 

;this communication notifies the serializer that device = j ha* completed printing 
;the value returned hy that operation is r and was expected by c 

(transmit_toc r) 

(ponder (a Hardcopy_server [device_statej: idle]))) 

((a Breakdown_report [request: =r] [device: device.j]) received 
(ponder (a Hardcopy_server 

[queue: (a Queue [front: r] [alLbutJront: queue])] 
[devastate-, broken]))))]))]) 
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We have adopted in this code and in our language a useful convention for giving 
default values to missing attributions in a description. For instance in the above code the 
expression 



a. 



(a Hardcopy server [queue: (a Queue [al^^ 

is considered to be equivalent to 

(a Hardcopy ^server 

[queue: (a Queue [al.Lbuljrear: queue] [roar: 1hejr«'ques(])] 

[device^statej: device_statej] 
[device_state2: devicejitate^]) 

This convention allows us to shorten our notation by avoiding the repetition of all the 
attributions that are left unchanged. 

Below we define the function ponder which maps behaviors onto behaviors 

(describe (ponder (a Hardcopy .server 

[queue: (a Queue [each_element: (a Print jrequest)])] 
[device.statej: (Ci idle printing broken)] 
[device^state 2 : (l!l idle printing broken)])) 
[is: (a Hard^copy ^server)] 
[implementation: 
($e!ect_ane_of 
(if (queue IS (a Queue [front: (a Request [message: *=r] [customer: =c])] 
[alLbutJront: =alLbutJrontq])) 
and (device jitate^ ^ 

then 

(transmit^to 4evk$\ 

(a Request [mensage: r] 

[customer: (create Jransaction_manager 
[request: r] 
[device: devicej] 
[customer: c])])) 
(become (a HanLcopyjierver [queue: alLbut JronLq] [device^statej: printing]))) 

(^(device^state! i$ broken) and (device_state 2 . i$ broken) then 
(trammit^to operator "Both printers are broken!") 
(become (a Hardj;opy_server))) 

[non©_of Jhe^above: 
(become (a Hard^copy ..server)}])]) 
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Note that a new transaction manager is created to manage each printing request 
for the hardcopy device. 

The actor createjransaction.manager (defined below) creates a serialized actor s 
wrapped inside a time_outJLno_re$ponse_after expression: 

{time_outJf_no_re$pon$e_after (10 minutes) 

which forwards to s any message it receives and also sends s a Time.out message after 10 
minutes if it has not received a response in the meantime. Requests for more funding are 
not considered to be responses and are passed through to s. Of course if the time-out 
expires after a response has been forward to s, then s is not bothered with a Time out 
message. 

Note that if a manager receives a Time.out message then it sends the hardcopy 
device an aborLprinting message waiting l minute for the device to respond using the 
following expression: 

($end_to d aborLprinting [time_outJLno_response_after: (1 minute)}) 

If the device responds with a Ready_for_next_request_report within l minute then 
the_hardco Py _server is told that the transaction has completed with a response which is a 
complaint that the allotted time has been exceeded. If the device does not respond to an 
aborLprinting message within l minute, then the_hard_co P y server is sent a breakdown report 
for the device and the operator is informed that the device is broken. 

The definitions given below are assumed to be inside the lexical scope of the above 
serializer thus making the_hardcopy_server lexically visible 



16 Guardians 

{describe (create Jransaction.manager [request: =r] [device: =d] [customer: =c]) 
[is: (a Serialized_actor [accepts: (l!l (a Response) (a Time_put))])] 
[implementation: {create^seriatized^actor (a Transactionjflanagfer [t»med_put: false]))]) 

{describe (a Transactionjrtanager [timed_out: (a Boolean)]) 
[implementation*. 

{time_out_if_no_respon$e_after (10 minutes) 
{create_unserialized_actor 

((a Response) =thej-esponse received 
{if (no/timed j>ut) 

Men {transmit^to the Jiardcopy ..server 
(a Completion 
[device: d] 

[response: the_response] 
[customer;: c}))) 
(become (a Transactionjnanager))) 
((a Time-out) received 

($elect_ca$eJor i$end_to d {an Abortprinting_request) 

[timej)utJLnoj*esponse„_after: (1 minute)]) 
((a ReadyJor^nexLrequesLreport) produces 
{tran$mit_to\\\Qjhardcopyj;ervGr 
(a Completion 

[device: d] 

[response: (a Complaint [message: allottedjime.exceeded])] 

[customer: c])) 
'■'.'. (become (a Transaction^manager [timed^out: true]))) 

((a Time-out) produces 

(fransm/'Lfo operator (a Breakdown^report [device: d])) 

(tran$mit_to thejiardcopyjierver (a Breakdown_report [request: r] [device: d])) 

(become (a Transaction jnanager [timed_out: true])))))))]) 

The statement 

(b(3COme (a Transaction„.manager [timed_out: true])) 

has the effect of causing the timed „out state component of the transaction manager to 
become true. Therefore any response addressed to that actor after its termination will be 
discarded since the code specifies 
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{if (not timed_out) 

then (tran$mit_to thejwdcopy.server 
(a Completion 

[response: the_response] 
[device: d] 
[customer: c]))) 
(become (a Transaction_manager)) 

In particular a response form a device will not be considered after a time-out has been 
generated. 



VI - PARTIAL SPECIFICATIONS OF A HARD-COPY SERVER 

Using primitive serializes, we have been able to deal with an important problem in 
the specification of guardians which allow time out. The problem is that if a guardian is 
allowed the possibility of time out in a partial specification how is it possible to rule out a 
trivial implementation which always times out. Our solution to this specification problem is 
to require that a guardian which receives a PrinLrequest PR which satisfies the following 
description: 

(a PrinLrequest 

[message: PR] 
[customer: C]) 

must eventually send one of the hardcopy devices a communication which satisfies the 
description 

(a Request 

[message: PR] 
[customer: M]) 

where M is a transaction manager. Furthermore if M receives a response before it receives 
a time out message then the response must be sent to C. 

This specification forces the hard copy server to at least try to satisfy the print 
request PR. It cannot simply wait 10 minutes and then transmit a time-out complaint to 
the customer C. 
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VII - PROOFS FOR THE HARD-COPY SERVER 

The proofs here assume that if both printing devices break down then at least one 
of them will eventually be revived by the operators. 

We first show that the preconditions on the behavior of the hard-copy server are 
always met These preconditions are useful in the r£st of the proof. 

The second part of the proof shows that the serializer completes each transition 
from a state in which it is unlocked to a state in which it is again unlocked. This will be 
a preliminary result for proving that the preconditions for the hard-copy server always hold 
Finally we prove that the guardian always replies to the requests which it receives. 

VII, 1 — Checking the Preconditions of the Behavior 

First we verify that the preconditions on the behavior of the hard-copy server 
always hold, namely: 

(queue /$ (a Queue [each.elemenh (a Printj*equest)])) 
(device^statej i$ {C\ idle printing broken)) 
(devic©..state2 /S (0 idle printing broken)) 

The proof that these preconditions always hold is by induction. 

L Show that the preconditions are met when the hard-copy server is created. 

2. Assuming that the preconditions are true, show that, whatever communication is 
received, the next become statement will produce a hard-copy server which meets the 
preconditions. 

It is clear by inspection that each of the three preconditions is true when the 
serializer is created After a communication is received, the function ponder is called with 
arguments satisfying the preconditions in creation of a behavior for ponder. This description 
can be used and gives us the fact we needed to complete the proof. Now to show that the 
implementation of ponder corresponds to its description, a similar technique can be used In 
this proof we will have to use the descriptions for the operations called by ponder. 

This part of the proof is not very different from the kind of static type checking 
usually performed by a compiler. 
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VII. 2 — ~ Proof of the Preconditions 

We want to show that whenever the guardian is unlocked, its state satisfies the 
precondition: 

(implies 

(queue /S -i(an Empty_queue)) 

(anc/ (device^statej is -iidle) (device_staie2 is -ijdle))) 

It is immediate that this precondition holds vacuously at the creation of the 
hard-e6py server since the queue is empty. 

The general result can be established by case analysis for each communication 
received. For instance if the guardian receives a PrinLrequest r in a state where the receipt 
preconditions hold, then the request r will be added to the rear of the queue and ponder 
will be called with a . non empty queue as an argument There are two cases to be 
considered (we are assuming the absence of breakdowns): 

j*m*^ h One of the devices is idle. Therefore by the 

precondition the queue contains only the request r. The request r 
is removed from the queue and the appropriate message is sent to 
the idle device. This reestablishes the precondition because the 
queue is once again empty. 

2: None of the conditions in the ponder transition is true, 
so that the none.ofjhe.above clause applies. Since the queue was 
not empty, this means that none of the devices was idle. Then 
the guardian unlocks becoming a hard-copy server with the state 
of both devices being not idle Therefore the precondition will 
hold again also in this case, 

The proof that the receipt preconditions hold when the guardian is unlocked is 
similar for the Completion communications and the Breakdown_report communications. 
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VII. 3 — Proof of Guarantee of Service 

We can prove that service is guaranteed to all printing requests. If the guardian 
receives a request when one of the devices is idle, the request will be immediately passed 
on, since the queue will be empty according to the precondition for the hard-copy server. 

If none of the devices is idle, then the request wiir be queued. 
The following assertion is proved by induction on n: 

If n requests precede a request R in the queue, then R will be 
passed to one of the devices after n completion communications have 
been received by the guardian. 

A completion is either one of the following communications: 

(a Completion [device: device^] [response: ...] [customer: ...]) 
(a Completion [device: device2] [response: ...] [customer: ...]) 

The implementation of the guardian has the property that the hardcopy server will always 
receive a communication back for each of the requests it sent to a device. By the 
precondition for the hard-copy server we know if R is in the queue, then there is a request 
outstanding for either devicej or device 2 , and a completion or a breakdown report will be 
received by the guardian. 

The first such communication will be received after a number p of print requests 
have been received by the guardian, p is finite because of the law of finite chains in the 
arrival ordering of actor systems [Hewitt and Baker 1977]. 

We can show that each of these p print request will leave unchanged the first n 
elements in the queue and will not alter the state of the devices. Consider then the effect 
of the next completion received by the guardian. We show that either the number of 
requests preceding R is decreased by one in the next unlocked state or the request R is 
sent to one of the printing devices. Clearly one effect of the completion is that one of the 
devices will become idle. Therefore the next request will be removed from the queue and 
passed to the free device. Therefore if n is 0, the request R is served. On the other hand 
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if n is bigger then 0, then removing the first element from the queue reduces by one the 
number of elements preceding R in the queue. 



VIII - ADVANTAGES OF PRIMITIVE SERIALIZERS 

We would like to discuss some of their advantages over previous proposals for 
language constructs for synchronization. 



VIII. 1 — Control Flow follows Text 

Each activity of the serializer is initiated by the receipt of a communication which 
causes the serializer to become locked. After a new receiver has been computed, it 
becomes unlocked and is ready to receive another communication. Unlike monitors, 
serializers have no explicit wait or signal command which cause the execution to be 
suspended and resumed from different points within the program. 



VIII. 2 — Absolute Containment 

Primitive serializers make it easy to implement guardians which do not give out the 
resources being protected. Instead a guardians passes messages from the users to the 
resources implementing a property which we call absolute containment which was proposed 
by [Hewitt: 1975] and further developed in [Hewitt and Atkinson: 1977) and [Atkinson and 
Hewitt: 1979] (cf. [Hoare: 1976] for a similar idea using the inner construct of SIMULA). 
The idea is to pass a message with directions to the resource so that it can carry out the 
directions instead of giving out the resource to the user. An important problem with the 
usual strategy of giving the resource out is that retrieval of the resource from a process 
that has gone amuck is often messy. 

We have found that absolute containment produces more modular implementations 
than schemes which actually gives out resources protected by guardians. Note that the 
proof that all requests will receive a re ponse from a network utility that implements 
absolute containment depends only on the behavior of the resource and the code for the 
serializer which implements the guardian, but not on the programs which call the guardiaa 
In the usual scheme of giving out the resource, it is necessary to prove that each process 
which can use the resource will give it back. 
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Our hardcopy server implements absolute containment by never passing out either 
of its hardcopy devices to the external environment Thus there is no way for others to 
depend on the number of physical devices available. Furthermore there is no problem 
retrieving the devices from users who have seized them since they are never given out 

VIII. 3 — Modularity in State Change 

Primitive serializes directly support a scheduling strategy of receiving each 
communication and then deciding what actions the communication requires. The possible 
actions include changing state and sending messages to other actors. , 

The only way to cause a state change in the programming language used in this 
paper is to use a primitive serializer. State change can be encapsulated within a serializer 
in a much more modular fashion than is accomplished by individual ASSIGNMENT and 
GOTO commands. In serializers state change and transfer of control are encapsulated in a 
single primitive that accomplishes them concurrently. We have found that this 
encapsulation increases the readability and modularity of implementations that require state 
change. 



VIIL4 — Generality 

In our applications we want to be able to implement guardians which guarantee 
that a response will be sent for each request received. This requirement for a strong 
guarantee of service is the concurrent analogue to the usual requirement in sequential 
programming that subroutines must return values for all legitimate arguments. In our 
applications it would be incorrect to have implementations which did not guarantee to 
respond to messages received. 

The SIMULA subclass mechanism was designed for sequential and quasi-parallel 
programming. It needs substantial revision for concurrent programming. The monitors of 
Hoare and Brinch-Hansen represented a substantial step towards generalizing classes for use 
in concurrent systems. However the use of explicit wait and signal commands on fifo queues 
or priority queues makes the scheduling structure of monitors somewhat inflexible. 
Furthermore it is difficult to prevent deadlock if monitors are nested within monitors. One 
strategy for implementing guardians with monitors is to use an ordinary SIMULA class 
whose procedures invoke a monitor which is local to the class. For example a hardcopy 
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server could be implemented as an ordinary class with a PRINT procedure which invokes 
REQUEST_PRINT, START.PRINT, and STOP.PRINT procedures in the monitor. Primitive serializers 
avoid the two level structure of monitor within class by explicitly dealing with the actors 
which act as customers to whom replies should be sent No special commands like wait and 
signal are needed because the customers are ordinary actors which can be remembered and 
manipulated using the same techniques that work for all actors. 

The utility of the extra generality in primitive serializers is illustrated by our 
implementation of the hardcopy^server in which we place a request which is not serviced 
because of the breakdown of a printer at the front of the queue of requests to be serviced 
Many synchronization primitives with more built-in structure (such as monitors) permit 
additions to queues only at the rear. 



VIII. 5; ~ - Conveniently Engendering Parallelism 

Primitive serializers provide a very convenient method for causing more parallelism: 
simply transmitting more communications. The usual method in other languages for 
creating more parallelism entails creating processes (cf. ALGOL-68, PL-1, Communicating 
Sequential Processes etc.). The ability to engender parallelism by transmitting 
communications is one of the principle differences between actors and the usual processes in 
other languages. For example in the implementation of the transaction manager in this 
paper, both the operator and theJwdcopy_server can be notified that a printer has broken 
down by simply transmitting the appropriate communications. 



VIII. 6 — Unsyncltronized Communcation 

In actor systems it is not necessary to know whether the intended recipient is ready 
to receive the communication; a guardian implemented using primitive serializers can 
transmit communications and then receive more messages before the communications which 
it has transmitted have been received. In our application involving the implementation of a 
distributed electronic office system, it is highly desirable that the sending of communication 
be unsynchronized from the receipt of the communication. 
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VIII. 7 — Behavior Mathematically Defined 

The behavior of primitive seriates can be read directly from the code. These 
mathematical denotations are intended provide a solid mathematical foundation on which to 
develop proof techniques and to provide a direct link with the underlying actor model of 
computation. Mathematical denotations have not yet been developed for the serializers in 
[Hewitt and Atkinson: 1977] or monitors because of the complexity of these constructs. 

VIII. 8 - Encouraging the use of Concurrency 

Primitive serializers permit implementations to use near maximum concurrency. In 
particular in contrast to the usual process model which only allows sequential execution 
within a monitor or critical region, primitive serializers encourage the use of concurrency in 
handling messages received. The only limitation on parallelism in systems constructed using 
ACT! derives from communications received by serialized actors when they are locked. 

VIII. 9 — Absence of Deadlock 

Primitive serializers have the important advantage that it is possible to guarantee 
absence of deadlock in actor systems by simply assuring that each individual actor will 
unlock after it receives a message. Absence of starvation (e.g. that every request received 
will generate a response) is more difficult to prove. 

VIIL10 — Ease of Proof 

We have found the above advantages of primitive serializers quite helpful in proving 
properties of implementations. Furthermore the structure of our proofs follows naturally 
from the syntactic structure of a primitive scrializer. The proof given in this paper that 
the hardcopy server will always respond to requests which it receives illustrates how 
primitive serializers facilitate proofs. 
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IX -- FUTURE WORK 

We are encouraged with the experience of using our description system to describe 
each of the programming problems considered in this paper. However it clearly needs 
much further development in pragmatic and behavioral descriptive power. 

One important area in which work remains to be done is to demonstrate that 
primitive serializers can be implemented as efficiently as other synchronization primitives as 
semaphores, monitors, etc. We have designed primitive serializers with this goal in mind. 
On the basis of some preliminary investigation we believe that they can be implemented at 
least as efficiently as monitors and communicating sequential processes. The third author 
has constructed some preliminary implementations in a dialect of the ACT1 language 
described in this paper which runs on the PDP-10. In the course of the next year, we will 
continue to work to improve this implementation and to transfer it to the MIT CADR 
machine where ultimately it can be supported by micro-code. 

Another area in which work remains to be done is automating proofs such as the 
one in this paper. We feel that we are getting close to the point where a Programming 
/0 m^ s Apprentice can do most of such proofs under the guidance of expert programmers. Russ 
Atkinson is working on automating the proofs for the version of serializers in [Atkinson 
and Hewitt: 1977] and [Hewitt and Atkinson: 1979]. We hope to be able to use some of 
the techniques which he has developed in our symbolic evaluator. 
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X -- CONCLUSIONS 

We are encouraged with our initial experience in working with primitive serializers 
and plan to develop them further. They appear have a number of important advantages 
over previous proposals for modular synchronization primitives. These advantages include 
ability to delegate communications [Hewitt, Attardi and Lieberman: 1978] and compatibility 
with the implementation of unserialized actors [Hewitt 1978} Event oriented specification 
and proof techniques are readily adapted to proving properties of guardians implemented 
using primitive serializers. These properties include the guarantee that a response is sent 
for each request received and a guarantee of parallelism [Atkinson and Hewitt: 1978], 
Note that the property of guaranteed response for each message sent cannot be proved in 
many models of computation because it implies the possibility of unbounded 
nondeterminism [Hewitt: 1978} In this paper we have shown how previous work on event 
oriented specifications and proofs can be extended to deal with time outs. 

Partial descriptions like the ones given in this paper are illegal in almost all type 
systems. The desire to be able make incremental multiple descriptions such as these has 
been one of the driving forces in the evolution of our description system. The SIMULA 
subclass mechanism is probably the most flexible and powerful type mechanism in any 
widely available programming language However, as a description system, it has some 
important limitations. It does not support interdependent descriptions or multiple 
descriptions. Also it does not permit instance descriptions to be qualified with attributions. 
Furthermore it does not permit descriptions to be further described thus disallowing any 
possibility of incremental description. 



27 Guardians 

XI - ACKNOWLEDGEMENTS 

Our colleagues at the MIT Artificial Intelligence Laboratory and Laboratory for 
Computer Science provided intellectual atmosphere, facilities, and constructive criticism 
which greatly facilitated our work. Major support for both laboratories is provided by the 
Advanced Research Projects Agency of the DoD. Additional support for this research was 
provided by the Office of Naval Research. 

During the spring of 1978, the first author participated in a series of meetings with 
the Laboratory of Computer Science Distributed Systems Group. These meetings were 
quite productive and strongly influenced both this paper and the Progress Report of the 
Distributed Systems Group [Svobodova, Liskov, and Clark: 1979} 

This paper has benefited from ideas that sprang up in conversations in the summer 
and fall of 1978 with Jean-Raymond Abrial, Gle~Johan Dahl, Edsger Dijkstra, David 
Fisher, Stein Gjessing, Tony Hoare, Jean Ichbiah, Gilles Kahn, Dave MacQueen, Robin 
Milner, Birger Moller-Pedersen, Kristen Nygaard, Jerry Schwarz, Steve Schuman, and Bob 
Tennent. The first author would like to thank Luigia Aiello and Gianfranco Prini and the 
participants in the summer school on Foundations of Artificial Intelligence and Computer 
Science in Pisa for helpful comments and constructive criticism. 

Valdis Berzins, Alan Borning, Richard Fikes, Gary Nutt, Susan Owicki, Dan 
Shapiro, Richard Stallman, Larry Tesler, Deepak Kapur, Vera Ketelboeter, and the 
members of the Message Passing Systems Seminar have given us valuable feedback and 
suggestions on this paper. Russ Atkinson is implementing a symbolic evaluator for the 
version of serializers in [Hewitt and Atkinson: 1977]. Vera Ketelboeter has independently 
developed a notion of "responsible agents" that is very close to the transaction managers 
described in this paper. Jerry Barber and Maria Simi have developed methods for proving 
that actor systems implemented with internal concurrency will respond properly to the 
messages which they receive. 

Although we have criticized certain aspects of monitors and communicating 
sequential processes in this paper, both proposals represent extremely important advances in 
the state of the art of developing more modular concurrent systems and both have deeply 
influenced our work. 

PLASMA [Hewitt and Smith: 1975, Hewitt 1977, Hewitt and Atkinson: 1977 and 
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concurrency as the core of the language. It was developed in an attempt to synthesize a 
unified system that combined the message passing, pattern matching, and pattern directed 
invocation and retrieval in PLANNER [Hewitt: 1969; Sussman, Charniak, and Winograd: 
1971; Hewitt: 1971], the modularity of SIMULA [Birtwistle et. ab 1973, Palme: 19731 the 
message passing ideas of [Kay 19721 the functional data structures in the lambda calculus 
based programming languages, the concept of concurrent events from Petri Nets (although 
the actor notion of an event is rather different than Petri's), and the protection inherent in 
the protected entry points of capability based operating systems. The subclass concept 
originated in [Dahl and Nygaard: 1968) and adapted in [Ingalls: 1978] has provided useful 
ideas. 

The pattern matching implemented in PLASMA was developed partly to provide a 
convenient efficient method for an actor implemented in the language to bind the 
components of a message which it receives. This decision was based on experience using 
message passing for pattern directed invocaiion which originated in PLANNER [Hewitt: 
IJCAI-69] (implemented as MICRO-PLANNER by [Charniak, Sussman, and Winograd: 
1971P. A related kind of simple pattern matching has also be used to select the 
components of messages by [Ingalls: 1978] and by [Hoare: 1978] in a design for 
Communicating Sequential Processes. However CSP uses assignment to pattern variables 
instead of binding which was used in PLANNER, SIMULA, and PLASMA. 
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APPENDIX I — Implementation of Cells using Serializers 

In this appendix we present an implementation of cells [Greif and Hewitt 
POPL-75, Hewitt and Baken IFIP-77] using primitive serializers. 

(describe (create.cell =initiaLcontents) 

[is: (a Serialized_actor [responds Jo: (ft (a Contents_query) (an Update))])] 
[implementation: 
(create_serialized_actor 

(a Celt [currenLcontents: initiaLcontents]))]) 

(describe (a Cell [currenLcontents: (an Actor)]) 
[implementation: 

(create_unserialized_actor 

((a Request [message: contents?] [customer: =c]) received 
(transmit^to c (a Reply [message: currenLcontents]))) 

;reply sending to the customer the current contents 

;unIock the scrializcr for the next message without changing the behavior 
((an Update [nexLcontents: =n]) received 

(tran$mit_to c (a Reply [message: (an Update4>erformed_report)])) 
(become (a Cell [currenLcontents: n]))))]) 
;unlock the serializer with the current contents heing n 

The above definition shows how serializers subsume the ability of cells to efficiently 
implement synchronization and state change in concurrent systems. 
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APPENDIX II — Implementation of Semaphores using Serializers 

Semaphores are an unstructured synchronization primitive that are used in the 
implementation of some systems. The definition below shows how primitive serializers can 
be used to efficiently implement semaphores. 

{describe (create^semaphore) 
[is: (a Serialized_actor 

[accepts: {ft (a Request [message: P]) (a Request [message: V]))])] 
[implementation: 

(create ^seriaiized^actor 
{a Semaphore 

[queue: (an Empty..queue)] initially there are no waiting P reauetl* 
[capacity:!]))]) ;the capacity i\< initially 1 

{describe (a Semaphore 

[queue: (a Queue [each_element: (a Customer)])] 
[capacity: (a Nonjiegativejnteger)]) 
[preconditions: 
{implies 

(queue /$ -»(afl Empty_queue)) 
(capacity is 0))] 
[implementation: 
(create_unserialized_actor 

{{a Request [message: P] [customer: =c]) received 

($elect_case_for capacity ' 

((> 0) produces 

{transmit^to c [reply: (a Completed J'j-eport)]) 
(become (a Semaphore [capacity: (capacity - 1)]))) 
(0 produces {become {a Semaphore [queue: (queue enqueue c )]))))) 
;hecome a semaphore tviih c enqueued at the rear of queue 

((a Request [message: V] [customer: =cj) received 
(tran$mit_to c [reply: (a Completed_V„report)]) 
(select^case^for queue 

((a Queue [front: =c] [alLbutJront: =resLwaiting..customer$]) produces 
{transmit^to c [reply: (a CompletedJ\.report)]) 
{become (a Semaphore [queue: resLwaiting^customers]))) 

((an Empty_queue) produces 
(become (a Semaphore [capacity: (capacity ♦ 1 )]))))))]) 

In [Hoare: 1975] there is an elegant construction showing that monitors can be implemented 
using semaphores and cells. His technique can be adapted to show that primitive serializers 
can also be implemented using semaphores and cells. 
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A PPENDIX III — Thumbnail Sketch of the Description System 

This appendix presents a brief sketch of the syntax and semantics of our description 
system. A paper which more fully presents the description system and compares it with 
other formalisms which have been proposed is in preparation. 

The description system is intended to be used as a language of communication with 
the proposed Programming Apprentice, Its syntax looks somewhat like a version of 
template English [Hewitt: 1975, Bobrow and Winograd: 1977, Wilks: 1976] Thus for 
example we write (an Integer) in this paper instead of writing (integer) as was done in 
PLANNER-71, However we also allow the use of instance descriptions such as 
(the Integer [>: 0] [<: 2]) to describe the Integer which is greater than and less than 2. 

We feel that it is quite important that a description expressed in template English 
correspond in a natural way with the intuitive English meaning. For this reason we use 
the indefinite article in attribute descriptions such as the one below: 

(4 is (an element of {2 4 6})) 

where the binary relation element can occur multiply in an instancy description such as 

(({2 4 6} is (a Set [element: 2] [element: 4]))) 

Note that (a Set [element: 2] [element: 4]) is a partial description of {2 4 6}. Attribute 
descriptions only make use of the definite article in cases like the one below 

((the imaginary_part of (a Real)) is 0) 

where the binary relation imaginary _part projectively selects the imaginary part of a Real. In 
this case the relation imaginary j>art might be inherited from Complex via the following 
description: 

((a Real) is (a Complex [imaginary_part: 0])) 
For the purpose of describing mappings, I prefer the syntax 

[=x>-> ...X...] 

[cf. Bourbaki: Book I, Chapter II, Section 3] to the syntax 
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(X X. ...X...) 

of the lambda calculus. For example the mapping cubes which takes a number to its cube 
can be described as follows: 

{describe cubes 
[is: t=nH-> n 3 ]]) 



XII. 1 — Examples 

XII. la — Articulation 

Articulation is an important capability of a description system. For example 
{describe cubes 

[is: (a Mapping [=nt-> n 3 ])]) 
can be articulated as follows: 

(cubes is (a Mapping [l»-> 1] [2^ 8] [3^ 27] [4H> 64] [5t-4 125] ... )) 
where ... is ellipsis. 

XII l.b — Sets and Multisets 

Sets and multisets can be described in terms of mappings using the usual 
mathematical isomorphisms. For example 

{describe {a b} 

[is: (a Mapping [ai-^ 1] [bn-^ 1] [-.a n ibi-> 0])]) 

describes the set {a b} as a mapping from a and b onto 1 since they are present in the set 
and everything else maps to since there are no occurrences of other elements. Extending 
the same idea to multisets gives the following example: 
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(describe {|a b a|} 

[is: (a Mapping [aM> 2] [b^ 1] [-,a n -ibn-> 0])]) 

which says that {|a b a)} can be viewed as a mapping in which a occurs with multiplicity 2, b 
occurs with multiplicity 1, and all other elements occur with multiplicity 0. 

XILl.c — Transitive Relations 

If (3 is (an Integer [<: 4])) and (4 is (an Integer [<: 5])), we can immediately conclude 
that 

(3 is (an Integer [<: (an Integer [<: 5])])) 

by the transitivity of predication. From this last statement, we would like to be able to 
conclude that (3 is (an Integer [<: 5])). This goal can be accomplished by the command 

/•"n (describe < 

[is: (a Transitive_relation [for: Integer])]) 

which says that < is a transitive relation for Integer and by the command below which says 
that if x is an instance of a concept which has a relationship R with something which is the 
same concept which has the relationship R with m where R is a transitive relationship for 
concept, then x has the relationship R with m. 

(describe (a ^concept [=R: (a ^concept [=R: =m])]) 

[preconditions: (R -is (a Transitive.relation [for: concept]))] 
[is: (a concept [R: m])]) 

The desired conclusion can be reached by using the above description with concept bound to 
Integer, R bound to <, and m bound to 5, 
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XILl.d — Projective Relations 

If (z /> (a Complex [reaLpart: 0)])) and (z -is (a Complex [real_part: (an Integer)])) then by 
merging it follows that (z i$ (a Complex [reaLpart: 0)] [real_part; (an Integer)])) However in 
order to be able to conclude that (z is (a Complex [reaLpart: 0) {an Integer)])) some additional 
information is needed. One very general way to provide this information is by 

(describe real_par t 

[is: (a Projeclive./elation [concept: Complex])]) 

and by the command 

(describe (a -C [=R: =descrip»ionl] [=R: =doscription2]) 

[preconditions: (f? is (a Projodivej-elation [concept: C]))] j 

[is: (a C [R: descriptionl der>cription2])]) s 

The desired conclusion is reached by -using the above description wilh c bound to Complex, R 
bound to raaLpart, descriptionl bound to (> 0), and description2 bound to (an Integer). 

This example cannot be done in most type systems; the above solution makes use 
of the w-order capabilities of our description system. 

XII. l.e - Self Description 

Self description provides the ability for the programming Apprentice to reason 
about its own procedures. However we must beware of paradoxes. For example the 
following sentence clearly holds in « order logic: 

VP Vx (P x) ifjand_on\yJi (P x) 
From the above sentence, we obtain the following by the usual rules for quantifiers: 

VP 3Q Vx (Q x) if_und_only_if (P x) 
Substituting the following mapping 

<=s H-Mnof <s s») 
for P, we get 
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2QV* (Qx) if _and_only J f (not (xx)) 
Using 3-elimination with Q for Q we get 

Vx (Q x) if_mdjon\yJf (not (x x)) 
Substituting Q for x we obtain Russell's paradoxical formula: 

iQoQo) iLand^only J f (not (Q Q )) 

However the above formula is a contradiction in our description system only if 
(Q Q ) is a Boolean which are described as follows: 

{describe (a Boolean) 
[is: (U true false)]) 

{describe true 
[is: 

^false 

(a Boolean)]) 

(describe false 
[is: 

-itrue 

(a Boolean)]) 

We propose to restrict the rules of logic to statements which are Boolean, For example the 
rule of double negation elimination can be expressed as follows: 

{describe (not (not =p)) 

[precondition: (p is (B Boolean))] 
[is* P]) 

In this way we hope to avoid contradictions in our description system. In the course of 
the iiext year we will attempt to adapt one of the standard proofs to demonstrate its 
consistency. 
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XII. 2 '— Axioms 

The description system is defined by its underlying behavioral semantics. The 
axiomatization given below is significant in that it represents a first attempt to axiomatize a 
description system of the power of the one described here. As far as I know previous to 
the development of this one, similar axiomatizations for FRL, KRL, OWL, MDS, etc. did 
hot exist 

The most fundamental axiom is Transitivity of Predication which says that for any 
<descriptiori3> 

Transitivity of Predication 

(implies 
(and 

(<descriptionj> /s <description2>) 
(<descriptiori2> /S <descriptiori3>)) 
(<d©scriptionj> /$ <descriptioti3>)) 

The descriptions in our system are completely intentional. Le. the fact that the 
extension of two descriptions is the same does not force the conclusion that the descriptions 
are coreferential. Suppose we. define snarks to be set of all animals which are both 
herbivores and carnivores. Then in Zermelo-Fraenkel set theory it follows that (snarks 1 cows) 
because the empty set is a subset of every other set From the following statements 

((a Snark) is (a Carnivore)) 
.■((a Snark) /£ (a Herbivore)) 
ila Carnivore) is . -»(a Herbivore)) 

we can conclude that 

((a Snark) is -.(a Herbivore)) 

by transitivity of predication. Thus we can conclude that nothing is a Snark because 
anything which is a Snark would necessarily be both a Herbivore and not a Herbivore. 
However this does not force the conclusion that 

((a Snark) is (a Cow)) 

Another important axiom is 
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Reflexivity 

(<description) is description)) 

which says that every description describes itself. 

Other important axioms are Commutativity, Deletion, and Merging: 

Commutativity 

((a ^description^ attributions j) <attributior>2> <altributions3> <attributiori4> <attributionsg>) is 
(a description j) <attributionsj> attribution^) <altributions3> attribution <attributionsg>)) 

which says that the order in which attributions of a concept are written is irrelevant Note 
that <attributions> is a string of zero or more elements of category attribution). 

Deletion 

((a description^) attributions^) <attribution2> <attributions3>) is 

(a <descriptionj> attributions^) <attributions3>)) 

which says that attributions of a concept can be deleted, and 

Merging 

{implies 
(and 

^description^) is (a <description2> <attributionsj>)) 
(<description|> is (a <description2> <attributions2>))) 
^description^) is (a <description 2 ) <attributionsj> <attributions2)))) 

which says that attributions of the same concept can be merged. 

Additional axioms 1 are given below for other descriptive mechanisms: * 

Coreference 

(description j> coref <description 2 >) ifjandjonlyjif 

^description^ is <description2>) and (<description2> is <descriptionj>) 



1: We are grateful to Dana Scott, Maria Simi, and Jerry Barber for helping us to remove 
some bugs from these axioms 
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Criteriality 

(implies 
(and 

^description^ is (the^only <description 3 >)) 
(<description2> is {the^only <description 3 »)) 
^description^ COref <description 2 >)) 

Constrained Description 

^description^ is «description 2 > $UCh_that <statement») ifjand^oniyjf 
{implies 

<statement> 

(<description 1 > /S <description2>)) 

Qualified Description 

«description 1 > is (<description 2 > thatjs <description 3 ») iLand^onlyJf 
(and 

(<descriptionj> /^ <description2>) 
(<d©scriptionj> /$ <d«scription 3 >)) 

View Point 

{^doscriptionjX viewed jas <description2>) is 

«description 2 > suchjthat ^description^ is <description 2 >))) 

Shift in Focus 

^description^ is (a <description 2 > [<descriptioh 3 >: <description 4 >])) if_and_onlyJf 

«description 4 > is (a <description 3 > of^description^ ' viewedjas (a <description 2 »))) 

Definite Selection 

((the description^ of (a <description 2 > ^description^: <description 3 >])> is <description 3 >) 

Complementation 

(-i-*<description> COref description)) 

«description 1 > is -.<description 2 » ifjandjonlyjf. (<description 2 > IS -^description^) 

CC<description|> is -i<description2>) implies 
(V =d 

(implies 

(d is <description|>) 

(not (6 is <description2»)))) 
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Meet 

(<descriptionj> is (l~l <description 2 > <description3>)) ifjandjonlyjif- 
(and 

(<descriptionj> is <description2>) 
(<descripiion^> /5 <descripliori3>)) 

((fl <description^> <description2>) /5 <descrip!ion2>) 

(-i(n <descriptionj> description coref (U -^description^) -i<description 2 >))) 

Join 

((U <descriptiori2> <descriptior»3>) is <descriptionj>) H^andjoniyjii 
{and 

(<description2> /$ <descriptionj>) 
(<description3> is description^))) 

(<doscriptionj> is (U <descriptionj> <description2>)) 

(«-»(U <descripiion 1 > <descriptiori2> COreMn -»<descriptionj> -i<description2>))) 

Disjoint Join 

<(l!l <descriptionj> <description2>) COtef 
(U 

(n ^description^ n<description2>) 
(il -i<descripiiorij[> <descripiiori2>))) 

Conditional Description 

(description^ is (<description 2 ) /7 statement))) ifjandjodyjf 
(<statement> implies ^description^) is Xdescriptk^))) 

XII. 3 --- Syntax 

If <x> is a syntactic category then an expression of the form <x>* will be used to 
denote an arbitrary sequence of zero or more items separated by blanks in the syntactic 
category <x>. An expression of the form <x> will be used to denote- an . arbitrary sequence 
of one or more items separated by blanks in the syntactic category <x>. 

The following is the syntax for descriptions and statements: 
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<descriplion> ::= (identifier) | 

=(identifier) | ;the character = i* used to mark local identifier* 

(statement) J ;note that statement* (which are described below) are description* 

(attributejtescription) | 

(attribution) | 

(instancejtescription) | 

(criteriaLdescription) | 

(mappingjJescription) | 

(sequence_descriptiqn) | 

(set.description) | 

(multiset_description> | 

(instance_description> | 

((description) viewed^as (description)) | 

((description) if (statement)) | 

(description) thatjs (description)) | 

(<description> such^that (statement)) | 

(H (description)) | ;D designate* the meet of desciptions 

(U (description)) | ;U designate* the: join of description* 

(l!j (description)) | ;L"J designates disjoint join of descriptions 

-i(description) | ;-• designates the complement of a description 

(<relalion> (description)*) 

(criteriaLdescription) ::== (th£_only (description)) 

;only used for descriptions that describe exactly one thing 

<instanc©„description> ::= <indefinitejnstance> | <delinitejns1anc©> 
(indefinite Jnstance) ::= «indefinite - article> (concept) (attribution) ) 
(definitejnstance) ::= {the (concept) (attribution)*) 

;definitejnstances are used only for criterial description* 
(indefinite^article) ::= a | an 

;there is no semantic significance attached to the choice of which article i* u*ed 
(concept) ::~ (description) ;note that this is w order 

(attribution) ::= [(binary j-elation_description): (description)] 

(attributions) ::= (attribution)* 

(bmaryj-etattonjiescriplion) ::= (description) ;note that this isio order 

. (aHribu!©_description> ::= (projective.attribute^descriptipn) | 

((indefinite^article) (binary_reiationjtescription) 6f (description)) 
(projective_attribute„description> ::- {the (binary_relation_description) of (description)) 
Expresses t hat (binary j-elationjescriptton) i\^ 
;*ee example below for an explanation of projective binary relations 
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<mapping_description> ::= [<description)M> description)] 

<sequenc© description) ::= [<elements..description>*] | 

<seLdescription) ::= {<elements.description)*} | ;{ and } are used to delimit *f?M 

<multiset_description) ::= {|<elements_description)*|} ;harred braces are used to delimit multiset* 
<elements_description> ::~ ... | 

description) | 

!<description> ;\ is the unpack construct 

statement) ::= ^predicate) description)*) | 
<predication> | 

(<description> COref description)) | statement of conference 
({<description)*j eachjs <description)) | 
{and statement)) | 
{or statement)) | 
{xor statement)) | 
{not <statement)) | 
^***\ {implies <statement) statement)) 

<predieation> ::= ((subject) is Complement)) 
<subject> ::= <description> 
Complement) ::= (description) 



